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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Patent Application of: 
Norbert BECKER et al. 

Application No.: Group Art Unit: 

Filed: (Concurrently) Examiner: 

For: SYSTEM AND METHOD FOR IDENTIFYING OBJECTS IN DISTRIBUTED 

HIERARCHICAL SYSTEMS, ESPECIALLY AUTOMATION SYSTEMS (as amended) 

PRELIMINARY AMENDMENT 

Assistant Commissioner for Patents 
Washington, D.C. 20231 

Sir: 

Before examination of the above-identified application, please amend the application as 

follows: 

IN THE TITLE: 

Please change "ESPECIALLY" to --IN PARTICULAR IN-. 
IN THE SPECIFICATION: 

Please REPLACE the pending specification with the Substitute Specification attached 

hereto. 

IN THE ABSTRACT: 

Please REPLACE the originally filed Abstract with the enclosed Substitute Abstract. 
IN THE CLAIMS: 

Please CANCEL claims 1 -2 without prejudice or disclaimer of any of the subject matter 
claimed therein and ADD new claims in accordance with the following: 

3. (NEW) A system for identifying objects in a distributed hierarchical system, 
comprising: 



a storage unit to store identifiers characterizing the objects and contexts for 
managing the identifiers, the contexts forming a plurality of indirection stages and, within a 
context, names and identifiers for all contained objects are known and unique. 

4. (NEW) The system as claimed in claim 3, the storage unit further storing container 
objects and context information for each container object, with the container objects containing 
other objects and the context information being hierarchically structured. 

5. (NEW) The system as claimed in claim 4, the storage unit further storing additional 
contexts which are not hierarchically related that may be unidirectionally associated with any 
desired context to access information thereof. 

6. (NEW) The system as claimed in claim 4, wherein the objects have associated local 
p object identifications stored in a lowest possible container object containing the objects, and the 
«3 objects are able to be identified using a chain of object identifications. 

||; 7 - (NEW) The system as claimed in claim 3, wherein the contexts include identification 

p contexts for managing context identifications, the context identifications being associated with 
W objects in the identification context and being valid and unique within the identification context. 

8. (NEW) The system as claimed in claim 3, wherein connections between the objects 
% are in the form of monikers. 

9- (NEW) The system as claimed in claim 3, wherein a document is provided as the 
smallest environment for a context, with context information associated with the document being 
used for objects embedded in the document, and the document having a name allocated 
thereto. 

10. (NEW) The system as claimed in claim 3, wherein the contexts are provided for 
managing the identifiers of the objects for object operations including at least one of moving, 
copying and renaming, without global, central management functions being provided. 

11. (NEW) The method as claimed in claim 3, wherein the distributed hierarchical 
system is an automation system. 
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12. (NEW) A method for identifying objects in a distributed hierarchical system in which 
objects are characterized with identifiers, and contexts manage the identifiers, comprising: 

storing the contexts to form a plurality of indirection stages, with all names and 
identifiers for all contained objects being known and unique within a context. 

13. (NEW) The method as claimed in claim 12, further comprising: 

storing container objects that contain other objects, and hierarchically structured 
context information for each container object. 

14. (NEW) The method as claimed in claim 13, further comprising: 

unidirectionally associating additional contexts, which are not hierarchically 
related, with any desired context to access information thereof. 

pi 15. (NEW) The method as claimed in claim 13, further comprising: 

*f storing in a lowest possible container object containing the objects, local object 

J identifications to identify the objects using a chain of object identifications. 

g 16 - (NEW) The method as claimed in claim 12, wherein at least some of the contexts 

W manage context identifications associated with the objects in a corresponding context and being 

y valid and unique within the corresponding context. 

II 17, (NEW) The method as claimed in claim 12, further comprising: 

0 storing connections between the objects are in the form of monikers. 

18. (NEW) The method as claimed in claim 12, further comprising: 

storing at least one document as the smallest environment for a context, with 
context information associated with the document being used for objects embedded in the 
document, and the document having a name allocated thereto. 

19. (NEW) The method as claimed in claim 12, wherein the contexts are provided for 
managing the identifiers of the objects for object operations including at least one of moving, 
copying and renaming, without global, central management functions being provided. 
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20. (NEW) The method as claimed in claim 12, wherein the distributed hierarchical 
system is an automation system. 

REMARKS 

This Preliminary Amendment is submitted to improve the form of the English translation 
as filed. It is respectfully requested that this Preliminary Amendment be entered in the above- 
referenced application. 

In accordance with the foregoing, claims 1-2 have been canceled and claims 3-20 have 
been added. Thus, claims 3-20 are pending and are under consideration. 

A substitute specification is also being filed herewith. The substitute specification is 
accompanied by a marked-up substitute specification. No new matter has been added. 

If there are any questions regarding these matters, such questions can be addressed by 
telephone to the undersigned. Otherwise, an early action on the merits is respectfully solicited. 

If any further fees are required in connection with the filing of this Preliminary 
Amendment, please charge same to our Deposit Account No. 19-3935. 



Respectfully submitted, 



STAAS & HALSEY LLP 




Richard A. Gollhofer 
Registration No. 31,106 



700 Eleventh Street, N.W. 
Suite 500 

Washington, D.C. 20001 
(202) 434-1500 
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System and method for object identification in 
distributed hierarchical systems, in particular in 
automation systems 



The invention relates to a system and method for object 
identification in distributed hierarchical systems, in 
particular in automation systems. 

Such a system and method are used particularly in the 
field of automation technology. 

The invention is based on the object of ensuring object 
identification for operations such as moving, copying, 
renaming, etc . 



This object is achieved by a system having the features 
specified in claim 1 and by a method having the 
features specified in claim 2. 

The invention is based on the insight that previous 
solutions are not very robust and/or require a great 
deal of modification effort. There are two basic 
identification mechanisms which are used (and can also 
be combined with one another) . One method is based on 
object identification by allocating a globally unique 
identifier for each object. This global identifier is 
used to ensure that an object can be found again 
irrespective of its present whereabouts. This method 
has the following drawbacks: 

• Central management: The method requires central 
management structures such as management of the 
object identifiers and conversion tables for the 
object identifiers to the objects. 

• Poor support for distributed work: The need for 
central management complicates 
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the splitting of object sets, separate processing 
and subsequent merging thereof (headword: branch 
and merge) . 

In the second method, an object is identified by its 
relative position with respect to another. This then 
also stipulates how the object can be found. In 
contrast to the first method, an object does not have a 
unique identifier, but instead the identifier [lacuna] 
dependent on the respective starting object referencing 
the other one. This means that no central management 
information is required. However, the following 
drawbacks result : 

• Low robustness: Using the relative position for 
identification means that the identifier (or the 
identifiers) becomes invalid when the object is 
moved, and the object is no longer available 
(broken link) . 

• Great deal of modification effort: When the 
identifiers for an object have become invalid, 
they need to be corrected using a type of 
correction operation. 

With the inventive solution, contexts are introduced 
for forming a plurality of indirection stages for 
managing the identifiers. This provides efficient 
methods for repairing "broken links" without 
introducing global, central management functions. 

• No central management: Management is through the 
context hierarchy. This means that each context 
contains all the necessary information. 

• Support for distributed work: The context 
hierarchy can be broken down and reassembled as 
desired. This means that projects can be branched 
and merged without difficulty. 

• Little modification effort: The context hierarchy 
makes it immediately clear where changes to 



identifiers are to be reconstructed. The changes 
also need to be made only on the context objects 
in question. 
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The invention is described and explained in more detail 
below using the exemplary embodiments shown in the 
figures, in which: 

FIGURE 1 shows a block diagram to identify the facts 
of the matter: a client sees names, an object 
model works with IDs, 

FIGURE 2 shows a schematic illustration for the 
allocation and assignment of object 
identifications as object IDs, and 

FIGURE 3 shows a schematic illustration for the moving 
of an object denoted by "ES-Autol". 

The method is described below within the context of the 
OVA engineering object model (OVA= open distributed 
automation) . It can also be used for other object 
models, however. For a better understanding of the 
relationships, a brief description of the context of 
the invention will be given below: 

For each object, there is an environment in which it is 
known. In the case of OVA, this environment is modeled 
by the context. Within a context, names and identifiers 
for all contained objects are known and unique. The 
context is generally determined by the point of entry 
chosen by a user for processing his automation 
solution. Context information is available on any 
container object (i.e. an object containing other 
objects) , such as H-container, chart or master. The 
smallest environment for a context is a document, 
however. For the case of embedded objects, the context 
information of the surrounding document is used. 
However, this also means that context information can 
be structured hierarchically. In this case, contexts at 
a lower point are always part of the higher context in 
the hierarchy as well. In addition, further contexts 
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which are not hierarchically related can be associated 
with any desired context. This context can then access 
the information of the associated context. This 
association is unidirectional, however. In the case of 
associated contexts, the (hierarchically) contained 
contexts are also associated automatically. 
The context information determines which objects have 
been entered in the directory. The content of the 
document automatically belongs to the same context; 
this also applies, in particular, to linked objects or 
objects which have been added using a rule ("all 
objects in this directory", etc.). 

The context is also the manager of the context IDs. 
These are described later. 

Object identification 

Since OVA uses a standardized method to access the data 
storage, it is necessary to structure the objects so 
that they can be safely identified. The reason for this 
is that some of the data are structure information, for 
example which ES-Auto is located in which chart, or 
which auto is connected to which. This structure 
information is subject to rules which are taken into 
account by the implementation of the data model. In the 
case of the current realization using the IStorage 
interface as the interface for data storage, it is 
always possible to change this structure without taking 
the data model into account. By way of example, a 
client is able to perform copy, move or rename 
operations using the IStorage interface without an OVA 
data model server being involved. This entails the 
problem that inconsistencies can arise which later need 
to be corrected again manually by the user. 
This now poses the problem of how consistency can be 
produced as far as possible without demanding excessive 
effort from the developer of ES -Autos or OVA tools for 
this purpose. These mechanisms should also not be 



o 
m 
m 
W 
m 
m 
o 
w 

•3 

I* 

© 

0 

14= 



GR 99 P 3135 

- 4a - 

transparent to the parts of the API which are used by 
the 
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OVA tools. A client application should always be 
occupied with the ES-Auto names, for example, and not 
with cryptic IDs (see FIGURE 1) . 

• Problematical actions 

It is first necessary to examine the actions which 
conceal potential risks. These are, firstly, all 
unidirectional relationships, and, secondly, actions 
which "pass by" the data model servers. 

• Unidirectional links 

Unidirectional links are problematical because it is 
not possible to tell from an action that an 
inconsistency is being produced. If a link is used to 
point to a file in a Word document, for example, and 
this file is renamed at a later point in time, the Word 
document is not told anything about this and will not 
find the file again. This problem can be eliminated 
only by a central authority which knows where the file 
can be found. 

• u Dumb" actions 

In this regard, dumb actions denote actions carried out 
without the knowledge of the data model . An example is 
25 renaming an object using the IStorage interface 
( IStorage : : RenameElement) . Such actions are always 
possible for standardized data access. In this case 
too, a central authority could help to minimize the 
problem. An important aspect in both cases is, above 
3 0 all, error recognition, and if possible also error 
elimination . 

• Object ID moniker 

As described above, a central office can manage the 
35 objects such that they are (virtually) uniquely 
identifiable. All the objects are therefore referenced 
using object IDs which can be resolved by the central 
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office, in our case the Active Directory Service. 
This ID is independent of all actions; it is allocated 
upon creation of the object and then does not change 
again 
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so long as no other object having the same ID exists. 
This will only occur in the case of copying outside the 
data model, however. 

Each container allocates a name when an embedded object 
is created. 

FIGURE 2 shows a schematic illustration of the 
allocation and assignment of object identifications as 
object IDs. These IDs, in the figure ID1, ID2 , ID3 and 
ID4, are respectively stored with their container. This 
means that the hierarchy container knows ID1 and ID2 , 
Chart 2 knows ID3 . In this regard, these IDs are unique 
only within the container on the topmost level. This 
means that Chart 1 can also start with ID1 again. 
Individual objects can now be identified using a chain 
of IDs . ES-Auto 1 is identified using /ID1IID1, for 
example. The connection between ES-Auto 2 and ES-Auto 3 
(IDy) is given the following IDs: 

IDy = /IDl!ID4!c -> /ID2!ID3!d 

IDy is thus a type of alias for the connection between 
ES-Auto 2 and ES-Auto 3. This alias is stored with the 
lowest possible container in the hierarchy. In this 
case, this is the H-container 1, since both Chart 1 and 
Chart 2 are involved in the connection. 

The connection IDx involves only the two ES-Autos 1 and 
2; the information relating to how IDx is resolved can 
therefore be stored with Chart 1. This procedure of 
keeping the information as local as possible has the 
advantage that these references can then be resolved 
even if only a subcontext is opened. In such a 
subcontext, all the references, connections etc. which 
remain within the context are thus known. Any 
references to the outside (or from the outside) cannot 
be resolved. 
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• Context IDs vs local IDs 

As can be seen in the example above, there are two 
different types of IDs. First the local IDs, such as 
ID1, ID2, which are only ever known locally to the 

container. Secondly, there are the context IDs, which 
have their validity within the whole of the current 
context. Both IDs need to be unique in their 
environment. The local ones at container level, the 
context IDs on a context -wide basis. 



• Resolution 

An ID needs to be resolved, for example, when the 
object is to be activated. Thus, for example, ES-Auto 2 
will check its connections during a consistency check. 
15 To this end, IDx and IDy need to be ascertained. To do 
this, ES-Auto 2 ascertains the individual objects from 
the context. Since the connections are stored as 
monikers, a BindToObj ect () is sufficient from the 
standpoint of the ES-Auto : 



MkParseDisplayName ( w @objectID! IDy! Source" , &pMoniker) ; 
pConnector = pMoniker->BindToObject () ; 



Since the monikers in this case are Object ID monikers, 
the server for Object ID monikers, that is to say the 
context, is asked for the object. The context knows 
IDy, because it is responsible for storing it, and 
3 0 resolves it into its component parts. The 
ParseDisplayName function extracts IDy and Source and 
establishes that this is /IDl!ID4!c. The containers are 
now recursively asked for this object. 



35 



This somewhat more complicated method is advantageous 
because the (possible) connections are also available 
in the subcontexts. In the example above, 
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Chart 1 could also be chosen as the entry point 
(context) . It is then also possible to access the 
connection IDx. In this case, IDy is an external 
connection which is not 
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available so long as the operator is moving only in the 
context of Chart 1 . 

• Use/examples 

The effects are now shown using a few examples. The 
actions are move, copy, delete and rename. 

• Move 

The initial situation is Error! Reference source could 
not be found. . ES-Auto 1 is now moved from Chart 1 to 
Chart 2 (see Error! Reference source could not be 
found.). This is done in two different ways. Firstly in 
an OVA tool, secondly past the data model ("dumb 
moving" ) . 

Moving in the OVA tool 

If the move operation is initiated in an OVA tool, the 
servers for the data model adopt the action and thus 
ensure that all references remain valid. The agitators 
involved in this case are the two charts. In the source 
chart, the method MoveESAuto is initiated. This method 
is provided with the ES-Auto and the destination chart: 

pChartl->MoveESAuto ("ESAuto 1" , pChart2); 

The method MoveESAuto thus encapsulates all the 
necessary steps. These are, firstly, copying the ES- 
Auto into Chart 2, then deleting the original auto from 
Chart 1 and finally matching the IDs. Since, with such 
an action, only the IDs up to the object on which the 
action was carried out can ever be altered, only this 
need actually be notified to the context: 
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pContext->UpdateReference ("ID1IID1", "ID2IID4") ; 

This method prompts the context to change all IDs which 
start with "ID1JID1" to "ID21ID4". 

FIGURE 3 shows a schematic illustration for moving an 
object denoted by "ES-Autol". 

w Dumb" moving 

With Mumb" copying, the servers for the object model 
are not involved. This means that the IDs cannot be 
updated either at this point in time. To perform such 
an action, it is sufficient to move the persistent data 
store for ES-Auto 1 from the store for Chart 1 to that 
for Chart 2. When Chart 1 is opened, it will no longer 
display ES-Auto 1 and will delete its entry for "ID1". 
When Chart 2 is opened, it will establish that an ES- 
Auto for which no ID has been allocated yet has been 
added to its data store. ES-Auto 1 is therefore now 
assigned an ID. In addition, the references for ES-Auto 
1 and the partners involved still need to be replaced. 
In the case of bidirectional IDs, this is not a 
problem. If ES-Auto 1 is asked for its external 
references, it will return IDx. If the context is asked 
for this ID, it can only resolve part ("ID11ID4") 
immediately. "ID11ID1" still points to nothing at this 
time. Since the action has been triggered by checking 
ES-Auto 1, however, this can be remedied (possibly on 
the basis of a query to the user) : 
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Foreach id In pESAutol- >GetExternalRef s () 
bOK = CheckRef erence (id. Source); 
if i bOK 

UpdateRef erence (id. Source, "ID2IID4") ; 
Endif 

bOK = CheckRef erence (id. Destination) ; 
if ! bOK 

UpdateRef erence (id. Destination, "ID2 1ID4") ; 
Endif 
Endf or 

• Copy 

The two methods will also be examined in the case of 
copying: 

Copying in the OVA tool 

If ES-Auto 1 is only copied, nothing needs to be 
changed on the references. For the destination ES-Auto, 
Chart 2 needs to allocate a new ID (for example ID4) . 
In addition, all the external references for the new 
ES-Auto should be deleted. 

"Dumb" copying 

If ES-Auto 1 is again copied past the object model, as 
in the case of moving, 2 ES-Autos refer to ES-Auto 2. 
This is not a problem, however, since in this case too, 
Chart 2 establishes that ES-Auto 1 is still not known 
to it (no ID) . As in the case of moving, it will now 
allocate a new ID and test the external references of 
the ES-Auto. In this case, ES-Auto 1 also exists in 
Chart 1, however. This check will therefore return no 
error. It is therefore necessary to check whether the 
unknown ES-Auto is part of the external reference. The 
code from above therefore needs to be extended a little 
further: 
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Foreach id In pESAutol->GetExternalRef s () 
bOK = CheckRef erence (id. Source) ; 
If ! bOK 

UpdateRef erence (id. Source, "ID2 1ID4") ; 
else 

If ! IsRef erenceParticipant ("ID2 1ID4") 

pESAutol->RemoveRef erence ( W ID2 I ID4") ; 

Endif 
Endif 

bOK = CheckRef erence (id. Destination) ; 
if i bOK 

UpdateRef erence (id. Destination, "ID2IID4") / 
else 

If I IsRef erenceParticipant ("ID2IID4") 

pESAutol ->RemoveRef erence ( U ID2 I ID4") ; 

Endif 
Endif 
Endf or 

• Delete 

When deleting an ES-Auto r the following steps arise: 
Deletion in the OVA tool 

If the ES-Auto is deleted, all the references can also 
be deleted immediately. In this case, the context is 
notified that a particular ID is no longer valid. This 
can now forward to all (on the basis of user query) 
objects having a reference to this ID the message that 
the ID is invalid. If ES-Auto 1 is deleted in Error! 
Reference source could not be found., for example, the 
following code needs to be executed: 
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RemoveRef erence (MD1IID1") ; 

The result of this call is that the context calls the 
method RemoveExternalRef erence () for all partners. 

w Dumb" deletion 

With dumb deletion, two situations can arise: the first 
possibility is for Chart 1 to be opened first. This 
chart establishes that an ES-Auto no longer exists for 
the ID1. It now deletes its entry "ID1". 

On the other hand, an object can attempt to resolve the 
reference (e.g. ES-Auto 2). Since this is not possible, 
the user is asked what has happened to ES-Auto 1, and 
what is meant to happen to the reference. 

• Rename 

Renaming is similar to moving. 

In summary, the invention relates to a system and 
method for object identification in distributed 
hierarchical systems, in particular in automation 
systems. To ensure object identification for operations 
such as moving, copying, renaming, etc., the invention 
proposes introducing contexts for forming a plurality 
of indirection stages for managing identifiers. This 
provides efficient methods for repairing "broken links" 
without introducing global, central management 
functions . 
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1. A system for object identification in distributed 
hierarchical systems, in particular in automation 
systems having means for forming a plurality of 
indirection stages for managing identifiers for 
obj ects . 

2. A method for object identification in distributed 
hierarchical systems, in particular in automation 
systems, in which the objects are identified by a 
plurality of indirection stages for managing 
identifiers . 
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TITLE OF THE INVENTION 

SYSTEM AND METHOD FOR IDENTIFYING OBJECTS IN DISTRIBUTED HIERARCHICAL 
SYSTEMS, IN PARTICULAR IN AUTOMATION SYSTEMS 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0001] The invention relates to a system and method for object identification in distributed 
hierarchical systems, in particular in automation systems. Such a system and method are used 
particularly in the field of automation technology. 

[0002] 

2. Description of the Related Art 

[0003] The invention is based on the insight that previous solutions are not very robust and/or 
require a great deal of modification effort. There are two basic identification mechanisms which 
are used (and can also be combined with one another). One method is based on object 
identification by allocating a globally unique identifier for each object. This global identifier is 
used to ensure that an object can be found again irrespective of its present whereabouts. This 
method has the following drawbacks: 

• Central management: The method requires central management structures such as 
management of the object identifiers and conversion tables for the object identifiers to the 
objects. 

• Poor support for distributed work: The need for central management complicates the 
splitting of object sets, separate processing and subsequent merging thereof (headword: 
branch and merge). 

[0004] In the second method, an object is identified by its relative position with respect to 
another. This then also stipulates how the object can be found. In contrast to the first method, 
an object does not have a unique identifier, but instead the identifier dependent on the 



respective starting object referencing the other one. This means that no central management 
information is required. However, the following drawbacks result: 

• Low robustness: Using the relative position for identification means that the identifier (or 
the identifiers) becomes invalid when the object is moved, and the object is no longer 
available (broken link). 

• Great deal of modification effort: When the identifiers for an object have become invalid, 
they need to be corrected using a type of correction operation, 

SUMMARY OF THE INVENTION 

[0005] An object of the invention is to ensure object identification for operations such as 
moving, copying, renaming, etc. 

[0006] With the inventive solution, contexts are introduced for forming a plurality of indirection 
stages for managing the identifiers. This provides efficient methods for repairing "broken links" 
without introducing global, central management functions. 

• No central management: Management is through the context hierarchy. This means that 
each context contains all the necessary information. 

• Support for distributed work: The context hierarchy can be broken down and 
reassembled as desired. This means that projects can be branched and merged without 
difficulty. 

• Little modification effort: The context hierarchy makes it immediately clear where 
changes to identifiers are to be reconstructed. The changes also need to be made only on 
the context objects in question. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] The invention is described and explained in more detail below using the exemplary 
embodiments shown in the figures, in which: 

FIGURE 1 is a block diagram of a method to identify the facts of the matter: a client sees 
names, an object model works with IDs, 

FIGURE 2 is a schematic object diagram for the allocation and assignment of object 
identifications as object IDs, and 



FIGURE 3 is a schematic object diagram for the moving of an object denoted by "ES- 

Autol". 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0008] The method is described below within the context of the OVA engineering object model 
(OVA= open distributed automation). It can also be used for other object models, however. For 
a better understanding of the relationships, a brief description of the context of the invention will 
be given below: 

[0009] For each object, there is an environment in which it is known. In the case of OVA, this 
environment is modeled by the context. Within a context, names and identifiers for all contained 
objects are known and unique. The context is generally determined by the point of entry chosen 
by a user for processing his automation solution. Context information is available on any 
m container object (i.e. an object containing other objects), such as H-container, chart or master. 
# The smallest environment for a context is a document, however. For the case of embedded 
f^l objects, the context information of the surrounding document is used. However, this also means 
CP that context information can be structured hierarchically. In this case, contexts at a lower point 
% are always part of the higher context in the hierarchy as well. In addition, further contexts which 
W are not hierarchically related can be associated with any desired context. This context can then 
i B access the information of the associated context. This association is unidirectional, however. In 
I* the case of associated contexts, the (hierarchically) contained contexts are also associated 
IK automatically. 

M [0010] The context information determines which objects have been entered in the directory. 
The content of the document automatically belongs to the same context; this also applies, in 
particular, to linked objects or objects which have been added using a rule ("all objects in this 
directory", etc.). The context is also the manager of the context IDs. These are described later. 

Object identification 

[0011] Since OVA uses a standardized method to access the data storage, it is necessary to 
structure the objects so that they can be safely identified. The reason for this is that some of the 
data are structure information, for example which ES-Auto is located in which chart, or which 
auto is connected to which. This structure information is subject to rules which are taken into 
account by the implementation of the data model. In the case of the current realization using 
the IStorage interface as the interface for data storage, it is always possible to change this 
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structure without taking the data model into account. By way of example, a client is able to 
perform copy, move or rename operations using the IStorage interface without an OVA data 
model server being involved. This entails the problem that inconsistencies can arise which later 
need to be corrected again manually by the user. 

[0012] This now poses the problem of how consistency can be produced as far as possible 
without demanding excessive effort from the developer of ES-Autos or OVA tools for this 
purpose. These mechanisms should also not be transparent to the parts of the API which are 
used by the OVA tools. A client application should always be occupied with the ES-Auto 
names, for example, and not with cryptic IDs (see FIGURE 1). 

• Problematical actions 

It is first necessary to examine the actions which conceal potential risks. These are, firstly, all 
unidirectional relationships, and, secondly, actions which "pass by" the data model servers. 

• Unidirectional links 

Unidirectional links are problematical because it is not possible to tell from an action that an 
inconsistency is being produced. If a link is used to point to a file in a Word document, for 
example, and this file is renamed at a later point in time, the Word document is not told anything 
about this and will not find the file again. This problem can be eliminated only by a central 
authority which knows where the file can be found. 

• "Dumb" actions 

In this regard, dumb actions denote actions carried out without the knowledge of the data 
model. An example is renaming an object using the IStorage interface 
(IStorage::RenameElement). Such actions are always possible for standardized data access. 
In this case too, a central authority could help to minimize the problem. An important aspect in 
both cases is, above all, error recognition, and if possible also error elimination. 

• Object ID moniker 

As described above, a central office can manage the objects such that they are (virtually) 
uniquely identifiable. All the objects are therefore referenced using object IDs which can be 
resolved by the central office, in our case the Active Directory Service. This ID is independent 
of all actions; it is allocated upon creation of the object and then does not change again so long 
as no other object having the same ID exists. This will only occur in the case of copying outside 
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the data model, however. Each container allocates a name when an embedded object is 
created. 

[0013] FIGURE 2 is a schematic illustration of the allocation and assignment of object 
identifications as object IDs. These IDs, in the figure ID1, ID2, ID3 and ID4, are respectively 
stored with their container. This means that the hierarchy container knows ID1 and ID2, Chart 2 
knows ID3. In this regard, these IDs are unique only within the container on the topmost level. 
This means that Chart 1 can also start with ID1 again. Individual objects can now be identified 
using a chain of IDs. ES-Auto 1 is identified using /ID1 ND1 , for example. The connection 
between ES-Auto 2 and ES-Auto 3 (IDy) is given the following IDs: 

IDy = /ID1!ID4!c-> /ID2!ID3!d 

[0014] IDy is thus a type of alias for the connection between ES-Auto 2 and ES-Auto 3. This 
alias is stored with the lowest possible container in the hierarchy. In this case, this is the H- 
container 1, since both Chart 1 and Chart 2 are involved in the connection. The connection IDx 
involves only the two ES-Autos 1 and 2; the information relating to how IDx is resolved can 
therefore be stored with Chart 1 . This procedure of keeping the information as local as possible 
has the advantage that these references can then be resolved even if only a subcontext is 
opened. In such a subcontext, all the references, connections etc. which remain within the 
context are thus known. Any references to the outside (or from the outside) cannot be resolved. 

• Context IDs vs local IDs 

[0015] As can be seen in the example above, there are two different types of IDs. First the 
local IDs, such as ID1 , ID2, which are only ever known locally to the container. Secondly, 
there are the context IDs, which have their validity within the whole of the current context. Both 
IDs need to be unique in their environment. The local ones at container level, the context IDs 
on a context-wide basis. 

• Resolution 

[0016] An ID needs to be resolved, for example, when the object is to be activated. Thus, for 
example, ES-Auto 2 will check its connections during a consistency check. To this end, IDx and 
IDy need to be ascertained. To do this, ES-Auto 2 ascertains the individual objects from the 
context. Since the connections are stored as monikers, a BindToObject() is sufficient from the 
standpoint of the ES-Auto: 
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MkParseDisplayName ("@objectlD!IDy!Source",&pMoniker); 
pConnector = pMoniker->BindToObject (); 

[0017] Since the monikers in this case are ObjectID monikers, the server for ObjectID monikers, 
that is to say the context, is asked for the object. The context knows IDy, because it is 
responsible for storing it, and resolves it into its component parts. The ParseDisplayName 
function extracts IDy and Source and establishes that this is /ID1 !ID4!c. The containers are now 
recursively asked for this object. 

[0018] This somewhat more complicated method is advantageous because the (possible) 
connections are also available in the subcontexts. In the example above, Chart 1 could also be 
chosen as the entry point (context). It is then also possible to access the connection IDx. In 
this case, IDy is an external connection which is not available so long as the operator is moving 
tfj only in the context of Chart 1 . 

8ft • Use/examples 

CJ [0019] The effects are now shown using a few examples. The actions are move, copy, delete 
*- r and rename. 

• Move 

[0020] The initial situation is Error! Reference source could not be found.. ES-Auto 1 is now 
O moved from Chart 1 to Chart 2 (see Error! Reference source could not be found.). This is 
done in two different ways. Firstly in an OVA tool, secondly past the data model ("dumb 
moving"). 

[0021] Moving in the OVA tool 

[0022] If the move operation is initiated in an OVA tool, the servers for the data model adopt the 
action and thus ensure that all references remain valid. The agitators involved in this case are 
the two charts. In the source chart, the method MoveESAuto is initiated. This method is 
provided with the ES-Auto and the destination chart: 
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pChart1->MoveESAuto ("ESAuto 1", pChart2); 



[0023] The method MoveESAuto thus encapsulates all the necessary steps. These are, firstly, 
copying the ES-Auto into Chart 2, then deleting the original auto from Chart 1 and finally 
matching the IDs. Since, with such an action, only the IDs up to the object on which the action 
was carried out can ever be altered, only this need actually be notified to the context: 

pContext->UpdateReference ("ID1ND1", "ID2ND4"); 

This method prompts the context to change all IDs which start with "ID1 !ID1" to "ID2IID4". 
[0024] FIGURE 3 shows a schematic illustration for moving an object denoted by "ES-AutoT. 
"Dumb" moving 

[0025] With "dumb" copying, the servers for the object model are not involved. This means that 
the IDs cannot be updated either at this point in time. To perform such an action, it is sufficient 
to move the persistent data store for ES-Auto 1 from the store for Chart 1 to that for Chart 2. 
When Chart 1 is opened, it will no longer display ES-Auto 1 and will delete its entry for "ID1". 
When Chart 2 is opened, it will establish that an ES-Auto for which no ID has been allocated yet 
has been added to its data store. ES-Auto 1 is therefore now assigned an ID. In addition, the 
references for ES-Auto 1 and the partners involved still need to be replaced. In the case of 
bidirectional IDs, this is not a problem. If ES-Auto 1 is asked for its external references, it will 
return IDx. If the context is asked for this ID, it can only resolve part ("ID1 !ID4") immediately. 
"ID1 !ID1" still points to nothing at this time. Since the action has been triggered by checking 
ES-Auto 1 , however, this can be remedied (possibly on the basis of a query to the user): 

Foreach id In pESAutol->GetExternalRefs () 
bOK = CheckReference (id. Source); 
if ! bOK 

UpdateReference (id.Source, "ID2IID4"); 
Endif 



bOK = CheckReference (id. Destination); 
if ! bOK 

UpdateReference (id. Destination, "ID2I1D4"); 
Endif 
Endfor 

[0026] 
• Copy 

[0027] The two methods will also be examined in the case of copying: 
Copying in the OVA tool 

[0028] If ES-Auto 1 is only copied, nothing needs to be changed on the references. For the 
destination ES-Auto, Chart 2 needs to allocate a new ID (for example ID4). In addition, all the 
external references for the new ES-Auto should be deleted. 

"Dumb" copying 

[0029] If ES-Auto 1 is again copied past the object model, as in the case of moving, 2 ES-Autos 
refer to ES-Auto 2. This is not a problem, however, since in this case too, Chart 2 establishes 
that ES-Auto 1 is still not known to it (no ID). As in the case of moving, it will now allocate a new 
ID and test the external references of the ES-Auto. In this case, ES-Auto 1 also exists in Chart 
1 , however. This check will therefore return no error. It is therefore necessary to check whether 
the unknown ES-Auto is part of the external reference. The code from above therefore needs to 
be extended a little further: 

Foreach id In pESAuto1->GetExternalRefs () 
bOK = CheckReference (id. Source); 
If ! bOK 

UpdateReference (id.Source, "ID2IID4"); 
else 

If ! IsReferenceParticipant ("ID2ND4") 

pESAuto1->RemoveReference("ID2!ID4"); 
Endif 
Endif 
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bOK = CheckReference (id. Destination); 
if ! bOK 

UpdateReference (id. Destination, "ID21ID4"); 
else 

If ! IsReferenceParticipant ("ID2ND4") 

pESAuto1->RemoveReference("ID2!ID4"); 
Endif 
Endif 
Endfor 

• Delete 

[0030] When deleting an ES-Auto, the following steps arise: 
Deletion in the OVA tool 

[0031] If the ES-Auto is deleted, all the references can also be deleted immediately. In this 
case, the context is notified that a particular ID is no longer valid. This can now forward to all 
(on the basis of user query) objects having a reference to this ID the message that the ID is 
invalid. If ES-Auto 1 is deleted in Error! Reference source could not be found., for example, 
the following code needs to be executed: 



RemoveReference ("ID1!ID1"); 

The result of this call is that the context calls the method Re move Extern a I Reference () for all 
partners. 

"Dumb" deletion 

[0032] With dumb deletion, two situations can arise: the first possibility is for Chart 1 to be 
opened first. This chart establishes that an ES-Auto no longer exists for the ID1 . It now deletes 
its entry "ID1". 



[0033] On the other hand, an object can attempt to resolve the reference (e.g. ES-Auto 2). 
Since this is not possible, the user is asked what has happened to ES-Auto 1 , and what is 
meant to happen to the reference. 

• Rename 

[0034] Renaming is similar to moving. 

[0035] In summary, the invention relates to a system and method for object identification in 
distributed hierarchical systems, in particular in automation systems. To ensure object 
identification for operations such as moving, copying, renaming, etc., the invention proposes 
introducing contexts for forming a plurality of indirection stages for managing identifiers. This 
provides efficient methods for repairing "broken links" without introducing global, central 
management functions. 
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Substitute Abstract 



ABSTRACT OF DISCLOSURE 



SYSTEM AND METHOD FOR OBJECT IDENTIFICATION IN DISTRIBUTED HIERARCHICAL 
SYSTEMS, IN PARTICULAR IN AUTOMATION SYSTEMS 



The invention relates to a system and method for object identification in distributed 
hierarchical systems, in particular in automation systems. To ensure object identification for 
operations such as moving, copying, renaming, etc., the invention proposes introducing 
contexts for forming a plurality of indirection stages for managing identifiers. This provides 
efficient methods for repairing "broken links" without introducing global, central management 
% functions. 
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Residence 

LAUFAMHOLZ.GERMANY 'T£^X 


Staatsa ngehongkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

GLASLEINSACKERWEG 25 


Post Office Address 

GLASLEINSACKERWEG 25 


90482 LAUFAMHOLZ 
DEUTSCHLAND 


90482 LAUFAMHOLZ 
GERMANY 


Voller Name des vierten Miterfinders: 

Dr. ALBRECHT DONNER 




Full name of fourth joint inventor: 

.DX.AI BRFCHT QQNNER 


Unterschrift des Erfinders 


Datum 


Inventor's signature / . H Date 


Wohnsitz 

MARKERSDORF, DEUTSCHLAND 


Residence 

JMARKERSBORE, GERMANY "IZ>£^7C 


Staatsa n ge ho rig keit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

HAUPTSTR.92 


Post Office Address 

HAUPTSTR.92 


09236 MARKERSDORF 
DEUTSCHLAND 


09236 MARKERSDORF 
GERMANY 


Voller Name des fiinffen Miterfinders- 

Dr. DIETER ECKARDT 




Fuli name of fifth joint inventor: 

Dr. DIETER ECKARDT 


Unterschrift des Erfinders 


Datum 


Inventor's signature Date 


Wohnsitz 

HERZOGENAURACH, DEUTSCHLAND 


Residence 

±lEBZ^KaENAiiRACH. GERMANY 77)/5^ 


Staatsa n geho ri g ke it 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

ZIEHRER STR 8 


Post Office Address 

ZIEHRER STR 8 


91074 HERZOGENAURACH 
DEUTSCHLAND 


91074 HERZOGENAURACH 
GERMANY 


Voller Name des sechsten Miterfinders: 

MANFRED KRAMER 


(trt>V_ 


Full name of sixth joint inventor. 

_MAMEBED-KRAMER — 


Unterschrift des Erfinders 


Datum 


Inventor's signature / / /' Date 


Wohnsitz 

WENDELSTEIN, DEUTSCHLAND 


Residence * * ^— " 

.WFNDFI SIE1N, GERMANY'lD^Tv 


Staatsa ngehorig keit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

FLIEDERWEG 21A 


Post Office Address 

FLIEDERWEG 21A 


90530 WENDELSTEIN 
DEUTSCHLAND 


90530 WENDELSTEIN 
GERMANY 



Falle von dritten und weiteren Miterfindern angeben). 



(Supply similar information and signature for third and 
subsequent joint inventors). 
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Voller Name des siebten Miterfinders: 

DIRK LANGKAFEL 


Full name of seventh joint inventor- 

. DIRK I ANGKAFEL 


Unterschrift des Erfinders Datum 


Inventory signature / / Date 


Wohnsitz 

EFFELTRICH, DEUTSCHLAND 


Residence * 

EFFELTRICH GFRMANY "X>£^X 


Staatsangehorigkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschnft 

BERGSTR. 15A 


Post Office Address 

BERGSTR. 15A 


91090 EFFELTRICH 
DEUTSCHLAND 


91090 EFFELTRICH 
GERMANY 


Voller Name des achten Miterfinders (falls zutreffend): 

RALF LEINS 


Full name of eighth joint inventor, if any: 

RALF LEINS 


Unterschrift des Erfinders Datum 


Inventor's signfetuneV % Date 


Wohnsitz 

ISPRINGEN, DEUTSCHLAND 


Residence § 

ISPRINGEN. GERMANY ""Z^^K 


Staatsangehorigkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

lM MAHLER 38 


Post Office Address 

IM MAHLER 38 


75228 ISPRINGEN 
DEUTSCHLAND 


75228 ISPRINGEN 
GERMANY 


Voller Name des neunten Miterfinders (falls zutreffend). 

RONALD LANGE 


Full name of nineth joint inventor, if any: 

RONALD LANGE 


Unterschrift des Erfinders Datum 


Inventor's signature . * Date 

(ZowejM X—^- 3723/0 J 


Wohnsitz 

FORTH, DEUTSCHLAND 


Residence 1 

FORTH. GERMANY ~X>^")C 


Staatsangehorigkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

VIRCHOWSTR. 28 


Post Office Address 

VIRCHOWSTR. 28 


90766 FORTH 
DEUTSCHLAND 


90766 FORTH 
GERMANY 


Voller Name des zehnten Miterfinders {falls zutreffend). 

KARSTEN SCHNEIDER 


Full name of tenth joint inventor, if any. 

_KARSTEN^OHNEIDER 


Unterschrift des Erfinders Datum 


Inventor's signature J \J I Date 

yv/v . /m.qi.o* 


Wohnsitz 

ERLANGEN, DEUTSCHLAND 


Residence (\ ^ 

ERLANGEN. GERMANY ~Z0 C?~X. 


Staatsangehorigkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

BOHLENPLATZ 7 


Post Office Address 

BOHLENPLATZ 7 


91054 ERLANGEN 
DEUTSCHLAND 


91054 ERLANGEN 
GERMANY 



(Bitte entsprechende Informationen und Unterschriften im (Supply similar information and signature for third and 



Falie von dritten und weiteren Miterfindern angeben). subsequent joint inventors). 
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Voller Name des elften Miterfinders: 

HELMUT WINDL 


Full name of eleventh joint inventor 1 

HELMUT WINDL - 


Unterschrift des Erfinders Datum 


1 n vento rVsig nalu reM~ 


Date 


Wohnsitz 

PEISIG, DEUTSCHLAND 


Residence* /S 

PEISIG. GERMANY ^XV^X 


Staatsangehorigkeit 

DEUTSCH 


Citizenship 

GERMAN 


Postanschrift 

FOHRENSTR.10 


Post Office Address 

FOHRENSTR.10 


93077 PEISIG 
DEUTSCHLAND 


93077 PEISIG 
GERMANY 


Voller Name des zwolften Miterfinders (falls zutreffend) 


Fuli name of twelvth joint inventor, if any: 


Unterschrift des Erfinders Datum 


inventor's signature 


Date 


Wohnsitz 


Residence 


Staatsangehorigkeit 


Citizenship 


Postanschrift 


Post Office Address 






Voller Name des dreizehnten Miterfinders (fails zutreffend): 


Full name of thirteenth joint inventor, if any: 


Unterschnft des Erfinders Datum 


Inventor's signature 


Date 


Wohnsitz 
j 


Residence 
j 


Staatsangehorigkeit 


Citizenship 


Postanschrift 


Post Office Address 






Voller Name des vierzehnten Miterfinders (fails zutreffend): 


Full name of fourteenth joint inventor, if any: 


Unterschrift des Erfinders Datum 


Inventor's signature 


Date 


Wohnsitz 
> 


Residence 


Staatsangehorigkeit 


Citizenship 


Postanschrift 


Post Office Address 







(Bitte entsprechende Informationen und Unterschriften im (Supply similar information and signature for third and 
Falle von dritten und weiteren Miterfindern angeben). subsequent joint inventors). 
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